home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
jdrbbs08.zip
/
DOCS_ETC.ZIP
/
DOCS_2.DOC
< prev
next >
Wrap
Text File
|
1993-04-06
|
169KB
|
3,053 lines
JDR_BBS .08
by
John Rohner
CONTENTS Line Topic
──── ───────────────────────────────────────────────────────
74 CUSTOMIZING 201
110 ANSI'S
272 ANSI Codes
372 LINES.TXT
437 SHORT.TXT
469 BLOCKS.TXT
497 SECURITY LEVELS
534 Ghosting
578 SYSOPS
590 FILE AREAS
732 Menus
813 Diagrammed File Options
911 Files In Area
925 Misc.
971 MESSAGE AREAS
1035 Menus
1047 PEER REVIEW
1096 WAITING FOR CALLER SCREEN
1185 SENDTT
1222 DATABASER
1233 BLOCKS.TXT DataBaser Structure
1405 Calling Via Menus
1416 Modifying
1419 Deleting
1438 More
1604 DIRECTRY'S
1706 USER HELP
1722 THE "WHO'S ON" STATUS LINE
1759 VOTING
1839 PSEUDO-AI
1851 ACCOUNT VALUE
1872 LIFE & DEATH DELETE
1907 FILE MANAGEMENT
1927 DOORS
1934 Defining
2030 Calling
2112 Executing
2181 Time Maintenance
2216 Misc.
2237 PROTOCOLS
2393 EVENTS
2406 NETMAIL AND ECHOMAIL
2409 Overview
2470 NetMail
2492 EchoMail
2560 FidoNet
2588 Hubs
2617 Costs
2635 Misc.
2670 Commands
2725 Not Ready
2744 MULTI-NODE/MULTITASKING OPERATIONS
2788 INTERNAL NETS
2824 FILE CORRUPTION
2852 TROUBLE-SHOOTING
2893 PERFORMANCE ENHANCEMENTS
2959 REGISTERED PACKAGE
2972 DataBaser
2974 Net Mail File Transfers
2988 Sysops Package
3051 NEXT
CUSTOMIZING When designing your BBS, there are three things you primarily
201 change: the menus (commands), the ANSI's, and the text.
You use McEditor to change the menu commands. Designing your
own commands or just moving around what is there.
You use TheDraw, or some other ANSI drawing program, to
design your ANSI's. Your ANSI's are the primary "look" of a
BBS.
You use LINES.TXT (and to a lesser extent BLOCKS.TXT and
SHORT.TXT) to change the text that is displayed. You have
complete control over all text. The words you choose provide
the "feel" of a BBS.
To change the text to a foreign language, change BLOCKS.TXT
and LINES.TXT. Then upload a copy to me, and I will include
it in the next release. For real language conversion, you
should also convert your ANSI's. Just dump all the files
into, say, NODE.002. This means that you must have language-
dependent phone lines, in a future release I'll add a
language menu to let users select between node's.
I strongly recommend that you do not change the sysop menu or
its ANSI's. The sysop menu (and its sub-menus) is actually
its own system--with the bottom 6 lines being a "window" for
routines to use. These menus will probably change with each
release.
The single key to turn the BBS "on" is to change the comm
port in "Change Settings", to something besides zero (like 1
for COM1:). Answer "N" to the "Null port?" question. You
will need to already have the fossil installed and defined in
your CONFIG.SYS.
ANSI'S All ANSI files may contain special "smart codes". These
codes, when encountered, will be replaced by something (see
below).
Smart codes take the form: xx<<yy, xx>>yy, xx><yy
Where "xx" is a number from 1 to whatever.
Where "yy" is a number from 0 to whatever.
Where "<<" means that the text corresponding to "xx" should
be left justified in a space of "yy" characters.
Where ">>" means that the text corresponding to "xx" should
be right justified in a space of "yy" characters.
Where "><" means that the text corresponding to "xx" should
be centered in a space of "yy" characters.
A "yy" of "0" means to "use whatever comes naturally"--no
squeezing if "yy" is too small, no extra spaces to fill up to
"yy".
By the way, the "" can be gotten in PC-Write with <alt>K, I
do not know what this is for other text editors.
Below is a listing of what the various "xx" numbers produce:
1 User's full name/company name. Name cased.
2 User's password/verification.
3 User's city & state/location. Name cased.
4 User's home/voice phone number.
5 User's BBS/data phone number.
6 User's birth date. dd-mmm-yy.
7 User's show security level value.
8 User's date they first called. dd-mmm-yy.
9 User's selected file transfer protocol. 1 character.
10 User's subscription start date. dd-mmm-yy.
11 User's subscription end date. dd-mmm-yy.
12 User's subscription type. 1 character.
13 User's available/unused monies sent.
14 User's total monies ever sent.
15 User's date of last call. dd-mmm-yy.
16 User's logons until must change their password.
17 User's date of last changing a L&D value. dd-mmm-yy.
18 User's first name. Name cased.
19 User's attempts to chat.
20 User's total number of logons/calls.
21 User's available minute-credits/extra download time.
22 User's hack attempts on name since last call.
23 User's total public messages posted.
24 User's total private messages posted.
25 User's total feedback to sysop messages posted.
26 User's total NetMail messages posted.
27 User's total NetMail messages received.
28 User's download minutes used today.
29 User's total number of files downloaded.
30 User's total number of bytes downloaded.
31 User's total number of minutes spent downloading.
32 User's total number of failed/bad download attempts.
33 User's total number of files uploaded.
34 User's total number of bytes uploaded.
35 User's total number of minutes spent uploading.
36 User's total number of failed/bad upload attempts.
37 User's total number of doors accessed.
38 User's Sysop-Note field.
39 User's User-Note field.
40 User's total messages ever posted.
41 User's total minutes allowed downloading per day.
42 User's total minutes allowed downloading left today.
43 User's elapsed time of the current logon/call.
44 User's age in years (goes by birth date field).
45 User's current connection baud rate/connection type.
97 BBS's phone number.
98 Sysop's full name. Name cased.
99 Sysop's first name. Name cased.
101 Current message area's title.
102 Current message area's message-op.
103 Current message area's minimum post SL value.
104 Current message area's minimum read SL value.
105 Current message area's minimum scan SL value.
106 Current message area's message-op's first name.
201 Current file area's title.
202 Current file area's file-op.
203 Current file area's minimum upload SL value.
204 Current file area's minimum download SL value.
205 Current file area's minimum scan SL value.
206 Current file area's file-op's first name.
│ 1001 to 1051 User counts for each of the 50 states.
│
│ 1100 to 1149 Top users ranked by DL bytes. Name cased.
│ 1150 to 1199 DL byte numbers for them.
│
│ 1200 to 1249 Top users ranked by files DL'd. Name cased.
│ 1250 to 1299 Files downloaded numbers for them.
│
│ 1300 to 1349 Top users ranked by UL bytes. Name cased.
│ 1350 to 1399 UL byte numbers for them.
│
│ 1400 to 1449 Top users ranked by files UL'd. Name cased.
│ 1450 to 1499 Files uploaded numbers for them.
│
│ 1500 to 1549 Top users ranked by logons. Name cased.
│ 1550 to 1599 Logon numbers for them.
│
│ 1600 to 1649 Top users ranked by msgs posted. Name cased.
│ 1650 to 1699 Messages posted numbers for them.
│
│ 1700 to 1749 Worst users ranked by DL bytes. Name cased.
│ 1750 to 1799 DL byte numbers for them.
│
│ 1800 to 1849 Worst users ranked by files DL'd. Name cased.
│ 1850 to 1899 Files downloaded numbers for them.
│
│ 1900 to 1949 Worst users ranked by UL bytes. Name cased.
│ 1950 to 1999 UL byte numbers for them.
│
│ 2000 to 2049 Worst users ranked by files UL'd. Name cased.
│ 2050 to 2099 Files uploaded numbers for them.
│
│ 2100 to 2149 Worst users ranked by logons. Name cased.
│ 2150 to 2199 Logon numbers for them.
│
│ 2200 to 2249 Worst users ranked by msgs posted. Name cased.
│ 2250 to 2299 Messages posted numbers for them.
│
│ For the top/worst users above, the number of users actually
│ stored depends on what you set in Alter Settings. You may
│ set it for more than 50, but you can only access up to 50
│ names this way.
Numbers are displayed with commas.
You should not use the "«" in any ANSI's before you get the
callers name (all ANSI's before your "LogN" command). This
character is used to tell the other computer when to receive
net mail--it may trigger a premature net mail transfer before
your BBS had planned. That is, if another BBS calls your BBS
looking for net mail, it is looking for this character--since
the BBS sends out this character to tell the calling computer
to begin a net mail receive. If it appears in your ANSI's,
it causes trouble. Once a user logs in, then you can use the
character in any of your ANSI's.
Auto-detect of Zmodem or BiModem is done at all menu ANSI's.
For menu ANSI's, the who's-on status line is displayed on the
next line following the ANSI--so it is not recommended you
have menu ANSI's that exceed 23 or so lines.
Menu ANSI's make an attempt to "hide" the cursor by putting
the cursor somewhere on the screen where it will not be seen.
See SHORT 442 for the command to use for this. Your ANSI's
may require a different position or color, etc. It is a
trick, and requires placing on a cursor position whose
foreground and background matches that of the cursor. Hard
to do at the console since the cursor is turned OFF.
│ If the file name has a "???" it will be expanded to the node
│ number. Any other wildcard, using "?" or "*" will cause one
│ file of those found to be randomly displayed.
ANSI Codes ANSI codes are marked by a distinctive "" as the first two
letters. The "" is an ASCII 27, and the easiest way to
create it in a text editor it to just copy it from another
line.
Code Meaning
──────────────── ───────────────────────────────────────────
r;cH Move the cursor to row r and column c.
r;cf Starting from 1 (1,1 = upper-left corner).
rH If c is excluded, then it goes to row r,
rf column 1.
xA Move cursor up x lines, or move cursor up
A one line.
xB Move cursor down x lines, or move cursor
B down one line.
xC Move cursor right x columns, or move cursor
C right one column.
xD Move cursor left x columns, or move cursor
D left one column.
s Save cursor position. Only one is saved,
so you can call this repeatedly and you
will still only get the last cursor
position you had.
u This puts you at the location your last
"s" was when you did it.
n Reports current cursor position. Report is
of the form: "r;cR"
Erase entire display and move cursor to
1,1. If a background color (besides black)
is in use then the whole screen will become
that color. To avoid this, use: ""
Clear from the current position to the end
of the line. If a background color
(normally black) is specified, this will
make that area that color.
v;w;x;y;zm Where v, w, x, y, z are any of the
w;x;y;zm following:
x;y;zm 0 Normal (dull white on black) text.
y;zm Turns off blinking and backgrounds.
zm 1 Bright on.
5 Blink on.
3x Foreground color (see x below)
4x Background color (see x below)
Colors (x): 0 = Black
1 = Red
2 = Green
3 = Yellow
4 = Blue
5 = Magenta
6 = Cyan
7 = White
ABCD above, the directional move codes, will not go beyond
the screen's borders. They also do not modify the "other
parameter" (be it row or column).
"xC" is particularly useful for efficiency. It moves the
cursor farther down the line x characters, so, if you wish to
move 5 or more spaces, or wish to "skip" 5 or more spaces
(such as when you have background colors on) then use this
rather than the spaces themselves, since it is less
characters to transmit.
The longest entry possible is something like:
"
". Which resets everything (0), turns bright
on (1), turns blink on (5), turns red on (31) and turns black
background on (40). What does this give us: bright red
blinking text on a black background.
Standard conventions: 0 first, 1 second, 5 third, foreground
fourth, and background fifth.
Most commands will usually only have two parameters:
"x;ym", where x is 0 or 1 and y is a foreground color. Use
0 to produce normal (dark) text and 1 to produce highlighted
(bright) text.
If the colors do not change, you can just use "
" to turn
bright text on. However, the reverse is not true ("")
since 0 alone resets the colors to white on black.
Example: "
T
esting"
Will produce a bright green "T" and a dark blue "esting".
Use of backgrounds is more tricky and requires practice and
patience. The key thing to remember: a "0" resets
everything. So to "undo" a background color, use a sequence
that starts with "" (ie. "").
LINES.TXT This is a standard text file that you may edit using any text
editor.
There are only five things to remember about the LINES.TXT
format:
The first four numbers represent a line number.
The remaining text is the text to send/display out.
The whole line cannot exceed 126 characters in length.
Color is done using ANSI codes.
Multiple lines can be used.
The first four digits of every line (except those designated
with a "'" to mark them as a comment, or "\\\\" to mark them
as a continuation) is a "line number"--not THE line number
which it occupies within LINES.TXT, but an assigned number.
Starting with position 5, the rest of the line (not counting
the CR/LF at the end of each line) is for the text that makes
up that line. There are two types of text: starting text,
and continuing text.
See the SendTT codes about the various "" options. The one
to pay attention to: "". This tells the software that the
next line should be wrapped to the end of this one--you
should then put "\\\\" as the first four characters of the
next line.
Here are a few useful locations:
0001 The logo line.
0002 BBS name (for doors).
0158 Shuttle logon password (if using it).
0625 Modem answer string (ATA).
0626 Modem initialization string (ATZ).
0627 Modem hang up string (ATH0).
0628 Modem take phone off-hook string (ATH1).
0626ATZ is of particular importance. ATZ is the
initialization string your communications program
sends to the modem upon startup. ATZ is for the HST-
-and possibly others--but certainly not for run-of-
mill 2400 baud modems. Consult the manual that came
with your modem to decide on what to use for its
initialization.
The rest of the lines are "just text". When you see
something displayed that you want to change--perhaps a
different wording--then search for it in this file and
replace it with what you want.
When JDR_BBS is run, it generates an image file and an index
file of your LINES.TXT--and it does not update the file
unless it senses that you have made changes to LINES.TXT.
Because LINES.TXT contains nearly all the text the program
uses, it is accessed a lot. So it should always be the first
file you think of when thinking about using a RAM disk. When
using multi-nodes, remember to define files that use the RAM
disk with different names (such as LINES???.$$$ for the image
file).
See also: SENDTT, ANSI'S
SHORT.TXT The SHORT.TXT file is structured very much like the LINES.TXT
files. Each line cannot exceed 126 characters, and the first
four characters are a line number.
Unlike LINES.TXT, however, you cannot wrap text to another
line. The entire SHORT.TXT file is loaded into memory (into
the string space).
The lines in this file mainly represent "system" stuff. Or
"language independent" stuff--text and stuff that does not
require translation to a different language.
Here are a few useful locations:
0001 to 0039 Words to censor out of descriptions.
0040 to 0049 Words to censor out of messages.
0050 to 0064 Words to upper case in messages.
0070 Entering messages: far background color.
0077 Entering messages: message body color.
0252 Words which cause chat rejection.
0350 to 0359 Words which cause search file rejection.
0820 Local call dialing prefix (an AT is added).
0839 Long distance dialing prefix (an AT is added).
0851 to 0860 <ctrl>Fx defined key menu commands.
0070, the far background color is 1;34 (a medium blue) now.
But most any color works good (including 1;30, a grey). I do
recommend you try the different colors (0;30 to 1:37) and
decide on one to your liking--different colors produce
very different looks for the message-entering system.
BLOCKS.TXT Blocks are lines of text that have the same first two
numbers.
Blocks contain various things: DataBaser definitions, text
blocks, "SelM" and "SelF" areas-to-use, and program blocks.
Usually anything over 5 lines is put into one of these
blocks.
In .09 I will be breaking this file up into about 5 smaller
files; each containing the same type of blocks.
Here is a couple useful locations:
07 AI's "go fish" message text.
37 "SelM" Net Mail message base selector I have set up.
49 Node address help--you should replace with your
node and BBS information.
63 "John's Address" option--change to your own.
69 .QWK mail "your BBS is" stuff.
78 Text for the terminal program.
For text blocks when using the "dBLK" command: a "" at the
end of the line will stop the output of a CR/LF when that
line is displayed (allowing for multiple lines to be merged)
and the final line does not get a CR/LF after it (allowing
the final line to be a question).
SECURITY The software will allow you to work with security levels in
LEVELS the range of -32,767 to +32,767. Using negative values,
however, might not be recognized in some routines.
There are no "locked in" security level values. Users may
have any security level value. The software will either use
their SL directly ("if SL < x then ...") or indirectly ("if
SL is > x and SL is < y then ..."). This allows you to use
the security level system as a "reward" and "punishment"
system if you want.
I just use a simple six level scale (5, 10, 20, 90, 95, 100)
myself, but you can do what you want.
When entering a range of SL's (some options allow this), you
must use " to " to separate the numbers (eg. "90 to 100").
Important: When entering the security level data in the
Security Levels database, you must enter the values in
increasing order (for example, 5, 50, 500--not 5, 20, 10).
So that when done, your first entry contains the lowest
value, and your last contains the highest. The highest is
assumed to be the sysop level. The lowest is assumed to be
the new user level.
After changing your SL's in the SL's database, you should run
"Update Stats", or you will just get nonsense when doing a
"Stats Display".
Do not mess around with the security levels for message area
001, Private Mail. All users need to be able to access this
area, so your SL's for accessing this area should always be
equal to, or lower, than your lowest defined SL.
SL's (used in commands, etc.) do not have to be an SL value
in your SL database.
│Ghosting Some BBS programs use "user flags" as an enhancement to their
│ SL system. A user would have to have both the SL and the
│ flag(s) to do a command.
│
│ I have a system just as powerful. It is called "SL
│ ghosting".
│
│ It is simple: you have two security levels; one that users
│ see, and one that the program uses.
│
│ When at the SL database, the real security level is referred
│ to as the "SL value" and the security level the user see's is
│ referred to as the "show SL".
│
│ This allows you to give a user of, say, real SL 4 30 minutes
│ per day, and one of real SL 5 60 minutes per day, while
│ having both of them think they are level 5 because both SL's
│ have a "show SL" of "5".
│
│ But besides simple user limits, the real use for this is with
│ menu commands. Providing a way to separate your users
│ internally without them knowing about it.
EXAMPLE
┌───────────────────────────────────────────────────────────┐
│Your BBS has the following time guidelines: │
│ │
│ Normal user: 60 minute limit per week │
│ Donated $1 : 70 minute limit per week │
│ Donated $10: 100 minute limit per week │
│ │
│Then in your SL database: │
│ │
│ Real SL Show SL Free Minutes │
│ 10 10 60 │
│ 11 10 70 │
│ 12 10 100 │
│ │
│Thus you have three different limits, three different SL's,│
│but the users never know it--they all think they are level │
│10. │
└───────────────────────────────────────────────────────────┘
SYSOPS For message bases, file areas, and doors. The sysop of that
area is the one true sysop in that area--the real sysop being
just another user.
For most other things, when I say "sysop only", what I really
mean is anyone with a sysop-level security level.
Pay attention to some of the commands, they offer different
options and displays depending on whether the user is a sysop
or not.
FILE AREAS The following can be set in Configuration in the File Areas
database.
Path
This contains the path to which this file area refers.
Title
Refers to what the users see when as the title when they
list the contents of that directory.
Download SL
Only when a user has at least that security value, will
they be able to download files from that area.
Upload SL
Only when a user has at least that security value, will
they be able to upload files to that area.
Access SL
Only when a user has at least that security value, will
they be able to list the contents of that area.
Attributes
│ The area may have eight attributes: 12345678.
"1" is DATE. Which means that you wish the file's date to
be shown when listing the contents of the area. The space
used by the date comes at the expense of the description.
Since file dates are often unreliable, I prefer the extra
description length for the UPLOADS area, but I do use the
date in the other areas.
"2" is LOG. Which means that you wish uploads and
downloads to/from this area to show up in the callers log
file in such a way that all users can see it.
"3" is L&D. Which means that you wish the L&D/Point values
to be shown when listing the contents of the area. Setting
this OFF overrides the user's toggle to view the L&D/Point
values.
"4" is UPLD. Which means that users may upload to this
area. When not included, any uploads attempted to this
area go to area number 001 (if possible).
"5" is ORDER. Normally files are listed in alphabetical
order (A to Z). When this is ON, files will be listed in
order from newest to oldest.
Normally when you have DATE ON, the current date of the
file on your disk is shown. But when ORDER is ON, then it
shows the date the file was uploaded instead.
│ "6" is TRANS. Which means that files in this area are said
│ to be "transient". This is for such as floppy or CD-ROM
│ drives--where you swap in and out disks of files. When
│ this is ON, auto-deletion of file entries not found is
│ turned off. Example: You have two floppies, each with two
│ files. With this OFF, each time you exchanged floppies the
│ system would automatically delete the file entries of the
│ files on the out floppy. With this ON, you can swap the
│ floppies without having to redo the descriptions each time
│ you swap in a new disk (although you do have to do them the
│ first time, like any new file). See the "MLsC" command.
│ "7" is NOEXT. Which means that when this is ON, no file
│ name extensions (.ZIP/.ARJ/etc.) will be shown on
│ description lines when listing a file areas contents. This
│ saves 4 characters per line, which can slightly speed up
│ output.
│ "8" is COUNT. Which will put the total number of files in
│ the area into the top header line when listing the contents
│ of the area.
Start Time
End Time
A user may download, list, or upload files to this area
only during the defined hours. Note that, starting an
upload or download inside the valid time, that then extends
outside the allowed time (eg. downloading a massive file)
will be allowed.
Circular buffer size.
If this field contains anything other than zero, than the
file area is said to have a "circular buffer". Whenever
the number of files in that area reaches this value, the
oldest file will be deleted. Example: if you set it to 50:
if there are 50 files in it, and someone uploads 3 files to
this area, then the oldest 3 files will be deleted. So
there will be 50 files again. If there were 45 files, then
it would have 48 files--since it did not reach 50, there
was no need to delete files. A zero value in this field
means there are no limits on the number of files that can
be active in this area (although you should make sure the
number does not exceed your "max files in dir" setting--see
SETTINGS).
Oldest file being the one in the area/on the BBS the
longest--not by current file date.
File-Op
This is a name field, and contains the name of the
"overseer" of that file area.
You, the sysop can do many file functions, including
delete, modifying the descriptions, etc. Including a name
here will allow that user to ALSO do these functions (only
one name allowed).
Only those with "sysop" security levels, or the name in
this file-op field will be able to "work on" files in this
file area. Useful for delegating the maintenance of a file
area to a user.
High-File-Pointer
This is a primarily internal field, its a storage location
for the highest HiFilePtr the area has seen. If you choose
to use the internal menu for switching file areas (versus
using an ANSI) then those areas with new files will be
highlighted for the user.
When you start up the BBS, it checks to see what files are
where, etc. If you accidentally renamed your downloads
directory, and did not update this in the File Areas database
(or vice-versa), then it is possible you could find that
startup procedure declared all your files deleted (and
recorded so in the log). Do not panic! Just get the
directory names correct, and restart. You will find that the
software, having realized its mistake, undeletes all your
file records. No files are ever actually deleted, it is just
the software doing some accounting for you.
Upload-stopping works as follows:
If the current area does not have UPLD, or the SL for the
area is too high for the user, then we change to area 001.
Then the same checks are made, if the user does not pass
them all, then they are not allowed to upload.
Menus The software will provide you flexibility to access your file
areas with whatever method you want. These include:
internally (quick) generated menu, ANSI menu, and continuous
systems.
Internally (quick) generated menus:
These involve making use of the "_Bxx" and "_all" some
commands have. "SelF _all", for example, will give you a
menu of all file areas you can access. "SelF _Bxx" will
retrieve BLOCKS.TXT block #xx (of the form: xxxyyyzzz...) and
produce a menu of those file areas to which you have access.
After the menu, the "SelF" command merely switches to that
file area. Other commands are "LstF", "PagF", and "Upld".
All work similarly with the "_all" and "_Bxx" by first
bringing up a menu and then Listing (continuous method),
Listing (paging method), and uploading to, respectively.
ANSI menus:
This involves putting individual commands into an ANSI. Once
again, the commands are: "SelF", "LstF", "PagF", and "Upld".
However, instead of using the "_Bxx" or "_all" extensions.
You use these commands with no extensions (except "SelF") or
with the "_xxx" extension (where "xxx" is a file area, eg.
001).
Additional commands of use are: "PrvF" and "NxtF"
Continuous systems:
These are extended listing systems. They include "PagQ",
"PagA", and "P&Sx".
"PagQ" will ask you what you want to do. "PagA" will cycle
though all the file areas accessible using the paged method.
"P&Sx" is the Point & Shoot system.
You can create a continuous system for the continuous method
of listing files as such:
LstF _001 LstF _002 LstF _003 LstF _004
This new command would cycle through your 4 file areas.
A common factor to all the systems is the batch download
buffer. It's accessed via commands in the paged method.
It's part of the P&S system. And you can use "CntB" and
"AddB" for ANSI menu options.
By having this wide variety of commands, you may put file
areas any where you want. You could, for instance, shove
them into a bunch, or break them up by topic--each having its
own message area, menu, etc.
From "P&Sx" if you hit "." you get a "LstF" of the current
area and it will loop through the rest of the areas using
"LstF", or until "." is hit again (when it returns to the P&S
screen). While the P&S screen won't show the users areas they
don't have access to, using "." to get into the "LstF"
version of "P&Sx" will show those areas, but say "SL to low
to access".
From "LstF" or "PagF" (but not "PagQ" or "PagA") "." will put
you into the P&S system. The P&S system will not show areas
the user does not have access to.
The commands can be thought of as differing ways of doing the
same thing. For instance, "PagQ" is one menu command, but
requires two key strokes to do something. You could do the
same with 4 menu commands ("PagA", "PagN", "PagF _all", and
"PagS") requiring only one keystroke. Same thing, different
philosophies for different sysops. Similarly, a function
like "LstF _all" is one command, but you could just as well
create a full menu with a bunch of individual "LstF _xxx"
commands (particularly so if you want your own menu's look
and feel).
See also: MENU COMMANDS: File
Diagrammed "LstF _001 LstF _002 LstF _nnn DReq" menu command:
File Examples ┌────────────────┐
┌────────┴───────┐REQUESTS│
┌────────┴───────┐ AREA n │ request│
┌────────┴───────┐EA 002 │ze desc │ request│
│ FILE AREA 001 │ze desc │ze desc │ request│
│ file size desc │ze desc │ze desc ├────────┘4
│ file size desc │ze desc ├────────┘3
│ file size desc ├────────┘2
└────────────────┘1
The user has to hit [Enter] to move to the next area. There
is no way to jump out of the areas (hitting [Enter] fast does
it). Recommended for less than 5 areas, or for when you have
areas you want to force the user to look at. All areas are
"attempted at", but the contents of areas to which users do
not have access are not shown. Listing method is continuous.
"LstF _all" menu command:
┌────────────────┐
┌────────┴───────┐AREA: │
┌────────┴───────┐EA 002 │a 001 │
│ SELECT AREA: │ze desc │a 002 │
│ A) area 001 │ze desc │a n │
│ B) *area 002 │ze desc ├────────┘1
│ C) area n ├────────┘2
└────────────────┘1
A menu is presented containing all the file areas. When they
select an area, they are given the contents listing of that
area (continuous method), and then return back to the menu.
Only areas to which the user has access are shown in the
selection menu.
"P&Sx" menu command:
┌────────────────┐
┌────────┴───────┐EA 001 │
┌────────┴───────┐ AREA n │le file │
┌────────┴───────┐EA 002 │le file │le file │
│ FILE AREA 001 │le file │le file │le file │
│ file file file │le file │le file ├────────┘1
│ file file file │le file ├────────┘3
│ file file file ├────────┘2
└────────────────┘1
The user has a wide selection of commands while at the P&S
display. You can move both forward and backward through the
file areas. Only those file areas to which they have access
do they see.
"SelF _Bxx" menu command:
┌────────────────┐
│ SELECT AREA: │
│ A) area 001 │
│ B) *area 005 │
│ C) area x │
└────────────────┘1
A menu is presented containing certain file areas (defined in
a BLOCKS.TXT block). When they select an area, they are
exited from the areas menu. Only areas to which the user has
access are shown in the selection menu.
"PagA" menu command:
┌────────────────┐
┌────────┴───────┐ AREA n │
┌────────┴───────┐EA 001 │ze desc │
│ FILE AREA 001 │ze desc │ze desc │
│ file size desc │ze desc │ │
│ file size desc │ ├────────┘3
│ Option: ├────────┘2
└────────────────┘1
Each file area is gone through. At every 18 file names or at
the end of a file area, a prompt is displayed. At this
prompt the user the user has a wide selection of commands
including commands to move to any area number. The listing
format is the paged method. This command is exactly the same
as "PagQ" with the user selecting "A" for all areas.
"PagF _all" menu command:
┌────────────────┐
┌────────┴───────┐AREA: │
┌────────┴───────┐EA 002 │a 001 │
│ SELECT AREA: │ze desc │a 002 │
│ A) area 001 │ze desc │a n │
│ B) *area 002 │ze desc ├────────┘1
│ C) area n ├────────┘2
└────────────────┘1
A menu is presented containing all the file areas. When they
select an area, they are given the contents listing of that
area (paged method), and then return back to the menu. Only
areas to which the user has access are shown in the selection
menu.
Remember that at the end of menu commands, you can put a
"DReq" to force the showing of the requests list.
The difference between a "PagA" and a "PagF _all" are in
scope. "PagF _all" is equivalent to a bunch of individual
"PagF _xxx"'s--so you cannot move between areas like you can
with "PagA" or "PagQ".
Files In Area When you place files in a download area--either copying or
downloading from another BBS--then these files are said to be
"outside the software's domain". That is, the software
does not yet know about it. So, some functions, that require
an active file's filename will not yet "see" the file.
However, as soon as they are "seen"--when you or a user lists
the files in a download area--then they are "discovered" and
given an entry, making them active.
When the software discovers files, the files are assumed to
be complete, and just given a blank description (shows up as
"?").
│Misc. The file system is optimized for lots of files in lots of
│ directories. Unless you have a fast computer, lots of files
│ in a few directories will be awkward. The reason for this:
│ because when listing each directory, the contents of that
│ directory are read into memory (from DOS) and then sorted.
│
│ Large collections of files in an area will also use up more
│ of your RAM, since appropriately sized arrays need to be
│ maintained.
│
│ What the limits are, are pretty much up to what you perceive
│ as too slow, or the conditions under which the BBS is
│ running.
│
│ Hundreds of files per directory are no problem on any system.
│ Thousands become a problem on slow computers.
│
│ To get around the slowness, use the "show by newest" toggle
│ when you want super-large file directories. You should also
│ then make the "maximum number of files per dir" setting
│ something more reasonable (but at least 100)--since the
│ software will not have to sort it, so this will change space.
│
│ If you REALLY want to screw up the software, have lots (like
│ 20) file areas with lots (like 2000+) files per. And with
│ some areas to be listed alphabetically and others by date-
│ uploaded. In this case, you really should have a 386.
│ Because sorting 2000+ files will probably show up as a sharp
│ delay before each file areas listing otherwise.
│
│ Example: Exec-PC has about 20 areas, by computer type, with
│ file counts ranging from 45,000 to a couple of hundred. He
│ uses a list-by-date-uploaded method. If you have a similar
│ system, that is what I would recommend. Using an
│ alphabetized list with thousands of files is wasteful.
│
│ But Exec-PC is a large pay-per BBS. Most BBS's specialize in
│ one type of computer. These have lots of areas, by software
│ topic, with not so many files. Example: 30 file areas with 1
│ to 300 files per. For this, either alphabetically or by
│ newest would do just fine. It is a sysops preference which--
│ I myself like to see the lists alphabetized and let the users
│ use "new stuff" or "PagQ with New" to list just the new
│ files.
MESSAGE AREAS There are 8 message area attributes: 12345679
"1" is ANONymous. Which means that the FROM: field will
contain "Anonymous" and nobody (but the sender) knows who
left the message.
"2" is PUBlic/PRIvate. Public means the messages posted
there are visible by all. Private means the messages are
only visible to the sender, receiver, or message-op.
When using the various message reading menu commands, pay
attention to which read private mail, and which read public
mail. They do not read each other's type.
"3" is NET. Which means that the area should be inspected
when receiving or sending Net Mail packets. It is also
necessary if you wish to enter a node address when entering
mail, and seeing the node addresses when reading mail. If an
area does not have NET, then no Net Mail will be put there,
and no messages will be sent out from there. Also, NET tells
the software to add special "^A" "kludge" lines to the
message.
You can really have only two NET-only areas: private NetMail,
and public NetMail. With private NetMail, any private Net
Mail that does not have a matching EchoMail message area will
be put here. Similarly for public NetMail. If you have only
one NetMail area, then both private and public NetMail goes
there. No NET areas? Then NetMail will be put into the
private mail area.
"4" is LOCK. Which means that the user must be unlocked to
to use the commands Read Mail, Leave Mail, and Scan Mail when
using this message area.
The message-op field is extremely important if you wish to
have locked/limited access to the message base. As ONLY the
message-op can lock/unlock users to that message base--even
the sysop cannot if they are not the message-op.
The locking system is also known as a conferencing system--in
which you allow or stop users from accessing the message area
without some sort of prior processing. The user has toggling
to turn ON and OFF message areas, the message-op has LOCKing
to turn users ON and OFF in message areas.
"5" is DEL. Which means that only the message-op can delete
any messages in the area.
"6" is ALL. Which means that all messages are given "ALL" as
their "TO:" field. This includes replies. Nobody is allowed
to enter a name in the "TO:" field.
"7" is ^A-ON. Which means that NetMail "kludge" lines are
shown (these lines begin with an ASCII 1--a little happy
face). This also toggles the showing of EchoMail lines: ---,
* ORIGIN:, SEEN-BY, and AREA:.
"9" is ECHO. Which means the area is an EchoMail area. NET
must also be set to on for any ECHO area. Basically, an ECHO
flag tells the software to add an AREA: line to each message.
You may mix-and-match the above attributes.
Menus The message area commands are quite similar to the file area
commands. For instance, "SelM" to select a message area is
just like its "SelF" brother.
Most of the other commands, for reading and writing messages,
are less generalized and usually only offer the non-parameter
form (uses the current area) and the "_xxx" parameter form
(switch to area "xxx" first and then do the command).
See also: MENU COMMANDS: Message
PEER REVIEW Peer Review is a restriction system--to restrict users.
To turn it ON for all new users, use "User Maintenance" to
set bit "0" to ON for #NEWUSER's attributes (you will need to
do this again if you re-initialize #NEWUSER). To turn it ON
for a single user, set bit "0" to ON in that user's record
with "User Maintenance".
When reading mail, when you, the sysop, hit "?", the message
is sent to a message file, and the user is tagged as
undergoing Peer Review. Should you hit "?" for another
message from a user undergoing Peer Review, then this message
is also added to the message file.
When users of a defined security level value range log on,
they may vote on these message files. To lessen the hassle
to those users in the range, they are only given one to do
per logon. Those already voted on are skipped, and users may
not change their vote. If the user hang's up while in the
voting mode, their vote is cast as "Don't Care" for that
review.
At each logon, a user undergoing Peer Review will be given
the tally so far.
When the number of positive or negative votes exceeds a value
you specify, then that user is said to have passed or failed
Peer Review. They will be given whatever SL value you
specified. A message will also be sent to them telling them
they passed or failed.
When a user passes or fails, that fact is recorded in the log
for all to see--so those who care about how the voting went
can find out. The complete review file is moved into
DEL_MSGS.TXT.
This system can be useful for limiting beginner users. It is
also useful for accounting. If you double-bytes-off a user,
and they go below their ability to download, the process
discourages "jumping to another account" and encourages one
to repair their account rather than abandon it.
When a user is undergoing Peer Review: during the login
process, if they do not have any mail waiting, they are
offered a chance to see what the voters see.
See also: SETTINGS, Ninf
WAITING FOR The Waiting-for-caller screen contains 5 "objects" of
CALLER SCREEN information: drive/mem stats, help/sysop info, modem status,
BBS status, and callers log.
The drive stats section, upper left corner of the screen,
shows the available memory on drives you have deemed
important enough to show this (in "Change Settings"). You
can hit <F5> to show some memory information instead. The
memory info is: amount of RAM the BBS "see's", amount of
internal string space and the amount of internal stack space
the software has.
│ The help section, upper right corner of the screen, shows the
│ various keys you may select at various times. You may page
│ these screens with the "+" and "-" keys. Hitting <F7> will
│ lock down (until a full exit is done) two stats windows: one
│ shows messages and files new to the sysop, the other shows
│ when the next event is scheduled for and when was the last
│ time the software checked to do events.
The callers log, bottom half of the screen, shows the last
few callers log entries. You may scroll this using the
up and down arrow keys.
The lines in the middle of the screen gives the time the
waiting-for-caller was started (time last user logged out, or
last event finished). It also tells how much time is left
before it resets the modem, and shows you a counter to that
time.
The 6 "buttons" are "CTS", "DSR", "DCD", "Trap", "Chat", and
chat availability.
"Trap" and "Chat" are ON (pushed in) when you have trap-all
or chat trapping ON.
"CTS", and perhaps "DSR", are usually ON or OFF depending on
your modem. Usually when a call is received the "DSR" will
go ON and then the "DCD" will go ON.
The final button is the chat availability toggle. This is
turned ON/OFF with F3 when at the waiting-for-caller screen
or when a user is on-line (a music symbol appears in the
status line when ON). When this toggle is OFF, the user will
not be able to try to chat with you. The symbols, "══" for
ON, and "═─" for OFF, breakdown as so: the left face is
that of the caller, the right face is that of the sysop,
there is a line of communication between the ears and mouths,
when you have your end turned OFF then you cannot hear what
the user is saying, but still can say something to the user
anytime you want (that is, the user cannot call you via chat,
but you can still jump into chat if you want to talk to him).
When the phone rings, a "[RING]" appears in the middle of the
screen.
After a carrier is detected, the string received by the modem
is displayed as it is received. A "│" marks a CR/LF.
After the phone rings, the software will start its "logo"
timeout countdown (I have it for one minute now). If no
carrier is found at that time, the phone is hung up.
When a carrier is found, the clock will stop ticking. The
"logo" time-out is reset, and starts (internally) again. The
string received by the modem is displayed as it is received.
Usually it will take a couple of seconds until connection
speed is determined. However, it could last the full "logo"
time-out time if the connection was one you had not specified
in your CONNECT strings database (for instance, this occurs
with 1200 baud callers when you do not want them). This is
because, for baud rates you do not want, the system merely
waits for that caller to hang up, or for them to time-out.
You will not be able to use any keys from the console during
this period.
Entries are recorded for "bad connects". They are of the
form: "Non user called at <time>. Connect: |...|". The
"|...|" is the crucial information. It will tell you the
exact string the software received from your modem. A bad
connection may contain just garbage, a 1200 connection would
look like "| 1200<garbage>|" usually. If you forgot any
CONNECT strings, this will tell you the information you need.
See also: SETTINGS, CONSOLE KEYS
SENDTT When ever the software uses its own text--that is, text users
do not enter--it searches for certain control information
within the text:
! will insert the sysop's first name.
? will insert the user's first name.
> to output a CR/LF.
+ to turn pause-allowed mode on ([Space] pauses text).
* for a 1 second pause.
-xx to produce "┌───┐" of length xx (must be two numbers).
|| (eg. |12Q~|) this sets up a list of stop-and-exit keys
for that line of text that the user can hit. For
[Enter] (an ASCII 13), use a "~" character. Not really
something useful to you, as there must be program
coding to make use of any keys hit.
@@ (eg. @E:\4THJULY.ANS@) will output the file between
the two @'s. This is useful for really long text or
ANSI strings. Can be used to add long special effects
to menu responses. No key checking--such as for
cancellation of output--is done during the display of
the file. You can use wildcard's to select a random
file from among whichever number match.
τ Will display your header line (LINES.TXT line 001).
_xx to produce "▄▄▄▄▄" of length xx (must be two numbers)
two lines below the current line.
These are codes for internal use only (either in BLOCKS.TXT
or LINES.TXT). These could not, for example, be put into an
ANSI file (such as menus) and expected to expand out.
They are filtered for (stripped out) incoming text,
imported, uploaded, and net messages.
The LINES.TXT file has another special code: which is not
a formatting code but a "there is another line" code.
DATABASER The DataBaser system is a sysop-designed data base system.
All DataBaser databases rely on BLOCKS.TXT to define and
"DBEd" or "DBVw" menu commands to implement--making them free
of the hardwired code.
However, I do use the DataBaser system for some of my own
internal databases (Message Bases, Sysops, Doors, etc.) which
may have some specific coding. Either way, for my internal
databases, you should not change the entries in BLOCKS.TXT.
BLOCKS.TXT Each DataBaser definition has a format along the following
DataBaser lines:
Structure Line 1: Descriptive text about the database. Appears
... when the menu command is called.
Line n: <end>
Line n+1: database's file name.
Line n+2: database's definition specs.
Line n+3: Question line to use when modifying.
Line n+4: The object name of the record type (subject of
the database).
Line n+5: Heading output text. Appears at top of listing.
...
Line n: <end>
Line n+1: Body output specs.
...
Line n: <end>
Line n+1 to end: text describing each field.
Example:
50
Fuzzy Bear's data base of warez.
50
50<end>
50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT
50S12S40U
50record number :
50warez
50 -------- Fuzzy'z Warez Data Baze -------->
50 Rec ==File Name== ===============Description============== ========User=======>>
50<end>
50
<04
<13 <40 <19~
50<end>
50File name
50Description
50User name
The "50" means this is block number 50 in BLOCKS.TXT (and it
comes only after block 49 and before block 51).
50
Fuzzy Bear's data base of warez.
50
50<end>
Is our description text. It can be any number of lines, but
must be at least two lines, and the last line must contain
only "<end>". It may contain SendTT formatting codes. A
CR/LF is assumed after each line.
When this database is called, it will clear the screen, print
the BBS heading, print "Fuzzy Bear's data base of warez." in
dark green letters, skip a line, then ask the "List, Add,
Modify, Delete, Insert, or [Enter] to quit" question.
50C:\BBS\GLOBAL\SYSTEM\FUZZY.DAT
This is the file name in which we store our database. You
can specify any pathname you want.
50S12S40U
This is the database's definition specs. The following are
currently allowed:
A for an attribute field. Inputs and displays attributes
using "1234567890ABCDEF".
F for file areas. Input is for a 3 digit number, but
output contains the number and the title of the area.
I for an integer number (-32767 to 32767).
L for a long number (-2,100,000,000 to 2,100,000,000).
M for message areas. Input is for a 3 digit number, but
output contains the number and the title of the area.
N for a node address (xxxxx:xxxxx/xxxxx).
P for a U.S. phone number.
Sxx for a string of length xx. xx must be two digits.
Example: for a string of length 4, use S04.
S02 is special: it is always replaced with a CR/LF.
S64 is special: it is considered to be a pathname, and
will be created if it does not exist and the entry you
make ends in a "\".
T for a time field (HH:MM:SS).
U for a users name. The auto-name-detect is in effect
so only active BBS users names are allowed. Use S30
for non-auto-name-detect name fields.
W for the seven days of the week (MTWRFSN). "R" for
thursday and "N" for sunday.
anything else will cause trouble.
Our example describes a database of 3 fields: a size 12
string field, a size 40 string field, and a user name field.
For a total record length of 82 characters (user names are
limited to 30 characters).
For those who need to know: A, F, I, M, T, and W are stored
in 2 byte integer form, L and P are 4 byte long form, U is a
30 byte string, N is a 6 byte string, and Sxx is a string of
length xx.
50record number :
This is the "modify which entry" question fragment. For
adding, deleting, inserting, etc. it asks "Modify with ..."
and appends the above.
50warez
This describes what we are working with. It is used when
adding. In this example, after selecting Add, it will
display "Adding a new warez."
50 -------- Fuzzy'z Warez Data Baze -------->
50 Rec ==File Name== ===============Description============== ========User=======>>
50<end>
Is our header text. It can be any number of lines, but must
be at least two lines, and the last line must contain only
"<end>". It may contain SendTT formatting codes. No CR/LF's
are added unless you put them in with ">".
50
<04
<13 <40 <19~
50<end>
This is our output display definition line. It contains two
defining elements: "<xx" which is the length to use, and
everything in between. For each definition in our definition
specs, there should be a corresponding "<xx". You cannot
not-do a field, but can not-show a field by using "<00". The
first one is for the record number. Two numeric digits are
required (for example, not "<9", but rather "<09").
The example tells the software to display a line of the
database as so: Turn bright green on, display the record
number in a area 4 characters wide, display a blank space,
turn bright blue on, display the filename in a area 13
characters wide, display a space, display the description in
an areas 40 characters wide, display a space, display the
user's name in an area 19 characters wide.
We could have used two spaces before <13 and used <12
instead, or no spaces before and <14 instead--since the field
is only 12 characters in length, the first two will always be
spaces.
The <19 truncates our 30 length file name. Output lines
cannot exceed 79 characters (the software chops off anything
longer).
A "~" will be replaced by a CR/LF.
All lines before the <end> are merged together before
handling is done--so instead of thinking of it as a bunch of
separate lines, think of it as one line broken up.
When displaying, the following formats are used:
Time: fixed "00:00 xm" format.
User name, String: left justified.
Integer, Long, Phone number: right justified.
Days of week: MTWRFSN with "off" days getting a space.
Attributes: 1234567890ABCDEF with OFF bits getting a space.
File/Message areas: "xxx title" with title left justified,
use <xx to limit what you want to see.
Node address: "xxxxx:xxxxx/xxxxx" format.
50File name
50Description
50User name
These are the field names used when entering/modifying a
record. Simple names, one for each definition spec.
When entering a day of the week, or attributes, they can be
in any order, MRF need not be entered as "M R F ", for
example.
Calling Via Calling up a database involves using a "DBEd" or "DBVw" menu
Menus commands.
Any user with access will be able to do all the functions
(List, Add, Modify, Delete, Insert) with "DBEd".
You can just list the contents of a database using the "DBVw"
menu command.
See also: DBEd, DBVw
Modifying When modifying the data, just hit [Enter] at the start of the
line to not change what is already there.
Deleting When deleting message bases, the MESSAGES file (and the
messages themselves) are not affected. If the deleted
message base has any active messages, then these will
"reappear" the next time you create a message base for that
message base number, or they will be deleted when you next do
a pack files.
Remember to not think of the entries as individual entries,
each entry holds a slot--and when you delete an entry, all
entries after it are moved down a slot. Delete record 4, and
record 5 is now record 4, record 6 is record 5, etc.
I strongly recommend that you do not delete stuff--but rather
modify the entries appropriately. This reduces confusion.
For records whose placement does not matter, deleting is no
problem, but for stuff like doors, where placement means what
menu command to use, it is extremely important.
More The above may at first seem confusing. But there are plenty
of examples. You will be using a lot of the already defined
databases. Use these to study how to really make what you
want.
When listing, all final lines are trimmed of trailing spaces.
If this is something you do not want, put something like a
"" after the spaces.
If an output line was only to output one field (not zero
fields, not more than one fields) and that field is blank,
then the line will not be outputted. That is, if an entry
uses the full line, and is blank, it will not be shown. This
is useful for large fields (eg. S64, S72) since the extra
lines these incur when listing makes reading more difficult.
EXAMPLE
┌───────────────────────────────────────────────────────────┐
│ Let us create a "news items" database. In which users │
│ can add/delete/modify/list entries of news items they │
│ think other users would be interested in. │
│ │
│ Step 1 │
│ Find a location for our DataBaser definition block in │
│ BLOCKS.TXT. Usually just use the next one following │
│ the last block in the file, for example, we will use │
│ 43. │
│ │
│ Step 2 │
│ Create some informational text for whenever this │
│ database is used. │
│ │
│ 43
Important news items you wish all to see. │
│ 43 │
│ 43<end> │
│ │
│ This displays "Important news..." in dark green │
│ coloring followed by a single blank line. │
│ │
│ Step 3 │
│ Assign a file name to store our data. │
│ │
│ 43C:\BBS\GLOBAL\SYSTEM\NEWS.DAT │
│ │
│ Step 4 │
│ Define the data structure to use. We want a more "free │
│ flowing" structure than normal. │
│ │
│ 43S72S72S72S72 │
│ │
│ Which is 4 lines of length 72 (4 string fields of │
│ length 72). We could add more (or less) of these, we │
│ could change their size, etc. But this provides a good │
│ balance between drive space and entry size (each entry │
│ will use 4 * 72 bytes of drive space). Also, it is a │
│ good size to fool the user into thinking they are not │
│ entering into a database--as it will look like a text │
│ file (when we are done). │
│ │
│ Step 5 │
│ Now we enter the text for the question when a user │
│ selects to modify a record. │
│ │
│ 43news item (1..n top down)?
│
│ │
│ Step 6 │
│ Identifying the record. "What it is" we are adding, │
│ etc. This is meant to be a singular noun. │
│ │
│ 43news item │
│ │
│ Step 7 │
│ Create a heading. │
│ │
│ 4326
News items of │
│ 43 interest.>> │
│ 43<end> │
│ │
│ We output "News items of interest.<ret><ret>" in bright │
│ green for our heading. │
│ │
│ Step 8 │
│ Design the record display line. Here is where we take │
│ advantage of some of the DataBaser system's qualities. │
│ │
│ 43<00 <72~ <72~ <72~ <72~ │
│ 43<end> │
│ │
│ We use " <72~" to print out each of the record lines │
│ with 4 spaces in front and a CR/LF afterwards. If the │
│ line/field is blank, then DataBaser will not output it, │
│ because it does not output lines with only one field, │
│ and with that field blank. The "<00" says to not │
│ output the record number (actually, it says "output the │
│ record number into a field of size 0). The last "~" │
│ will result in an extra CR/LF between the outputted │
│ records. │
│ │
│ So, now when we list, it will list all entries, │
│ separated by a blank line. It will only list as many │
│ lines per entry as contain data. Example: an entry │
│ with 2 lines of text shows only 2 lines, etc. Not a │
│ steady 4 lines per output record, even though the │
│ record can work with up 4 lines--by stopping output of │
│ "blank" lines, the actual number of displayed lines │
│ will vary with the number of fields witch actually │
│ contain data. │
│ │
│ 43
}7<02
<72~ <72~ <72~ <72~ │
│ 43<end> │
│ │
│ Could be used to display the item number as well. │
│ Above the items appear in the default dark white color, │
│ here we turn on dark blue for the number, and dark │
│ white back on for the text. │
│ │
│ Remember, this entry does not define how each line of a │
│ record is to be displayed, but rather how the whole │
│ record is to be displayed. │
│ │
│ 43<00|o| <72|o|~|o| <72|o|~|o| <72|o|~|o| <72|o| │
│ 43 <*-+-*> │
│ 43 |o| │
│ 43<end> │
│ │
│ This is another example. This displays each item in a │
│ "paper feeder" like format. With a short design as a │
│ separator. Remember that the lines are all linked │
│ together to form a single string. │
│ │
│ Step 9 │
│ Because we have defined four fields (S72 * 4) we must │
│ now give each a name (for when we add/modify the │
│ entry). │
│ │
│ 43Item │
│ 43Item │
│ 43Item │
│ 43Item │
│ │
│ When adding/modifying an entry, we will be adding to 4 │
│ fields with the same name. But because the whole │
│ record is considered a single news item, this is quite │
│ appropriate. │
│ │
│ Finally │
│ We have completed a new database. Now we just give it │
│ an entry on a menu's ANSI, and a matching entry in │
│ McEditor with the command "DBEd _B43". Review the menu │
│ system for help with this procedure. │
│ │
│ NOTE │
│ While this database was designed to let users add │
│ entries, you can utilize it as your primary news file │
│ as well. Either replace the "Dnws" with a "DBVw" or │
│ add a "DBVw" command before or after "Dnws". Then when │
│ users log on, they will get a listing of your news │
│ DataBaser contents. │
│ │
│ One drawback with this database--any user can modify │
│ any other user's news item. Well, it might actually be │
│ useful here, but it would be disastrous if this were, │
│ say, a Buy/Sell/Swap database. │
└───────────────────────────────────────────────────────────┘
DIRECTRY'S Directry's are collections of information stuck into one
file.
There are three files for each directry: DIRECTRY.Dxx,
DIRECTRY.Txx, and DIRECTRY.Ixx. The software creates
DIRECTRY.Ixx.
DIRECTRY.Dxx contains the information. This file can have
three formats:
LINE files consist of: LINE
HEADER/NOHEADER
%%%
text line 1
text line 2
text line 3
. . .
text line n
Use LINE formatted files for when the information uses only
one line. Lines should not exceed 126 characters.
BLOCK files consist of: BLOCK
HEADER/NOHEADER
%%%
text line 1
. . .
text line n
%%%
text line 1
etc.
Use BLOCK formatted files for when the information uses
multiple lines. Lines should not exceed 126 characters.
LENGTH files consist of: LENGTH
HEADER/NOHEADER
%%%
size
text of size bytes
%%%
size
etc.
Use LENGTH formatted files for when the information is of
text either not having CR/LF's or that with lines of more
than 126 characters in length. There is no limit on the
size of the text.
The key information to remember: The first line contains the
information type (LINE, BLOCK, or LENGTH). The second line
contains whether the screen should be cleared and the logo
(LINES.TXT line 001) displayed (HEADER/NOHEADER). The third
line is our first "separator line" and consists of "%%%".
From then on we alternate between information and "%%%"
lines.
DIRECTRY.Txx files are of the form:
First line: Line of text that makes up the heading.
2nd line: Text of the question to ask.
n lines: n lines of titles for each information element in
the DIRECTRY.Dxx file.
Lines should not exceed 126 characters in length. The size
of the longest title determines how many titles are put on
each line for the selection menu.
xx corresponds to a value of 01 to 99. Directry files need
not be in sequential order: 5, 19, 37, 88 or 1, 2, 3, 4 are
OK.
See the menu commands for information on setting it up in a
menu.
For LENGTH files, the only real way to determine the lengths
is by trial and error. But file lengths are usually correct
(the length of the text when it is in its own file).
For title (.Txx) files, using a max title width of 20 will
get you 3 entries per line.
When called, the list of titles will be displayed, a
selection made, and the information corresponding to that
selection/title will be shown.
The whole system is designed for you to create whatever
DIRECTRY's you want--up to 99 of them. I have included
samples of each type.
Use HEADER if you want the BBS logo header line to be
displayed over each data item. Use NOHEADER if you do not
want anything displayed over the data item (usually implies
the data item will handle it). Anything else besides HEADER
or NOHEADER will be displayed over the data item.
You can use SendTT ("") codes in the data text.
Just use a text editor to create/modify the .Txx and .Dxx
files, then just restart the BBS--the .Ixx files are
built/updated automatically.
See also: DirV, SendTT
USER HELP My setup is designed to give users help by files. Such as
the BBS Information file and the Additional Information file.
However, another method is available: using a BLOCK Directry.
In which each block represents a different topic. I have no
example set up--but it is similar to the Unprotect Directry.
It is a way of putting all your information into one place,
including information about you, the system, your rules,
uploading/downloading, help using the BBS, etc. For
instance, this would be an exact alternative to using a lot
of messages to give this information.
Indeed, a Directry labeled: "Frequently Asked Questions"
would probably be useful.
THE "WHO'S ON" Below each menu ANSI, the console will see a user status
STATUS LINE line.
It looks something like this:
User Name--Location 5sl 10calls 2msgs ctn
Which breaks down as:
"User Name" is just that, the callers name.
"Location" is the callers city and state. If flashing,
then this is the text they typed for a chat
request.
"5sl" is the callers security level value ("5") based on
their current (or temporary) grouping. Example: if
you an SL range of 5 to 9, and this user has 7, it
will still show 5. It is done this way so you can
see the effects of your <home>/<end> efforts.
"10calls" is the number of times the caller has called.
"2msgs" is the number of messages the caller has ever
posted ("2").
"c" appears if chat trap-to-file is on.
"t" appears if trap all to file is on.
"n" appears if sysop-on-next is on.
"PR" appears if the user is undergoing Peer Review.
A music symbol when you are allowing users to try to chat
with you.
Other information that appears:
"+5'd" after you just increased their session time by 5
minutes.
"-5'd" after you just decreased their session time by 5
minutes.
"SL+" after you just increased their SL by 1 level.
"SL-" after you just decreased their SL by 1 level.
"SL^" when you have reached the maximum SL.
"SL_" when you have reached the minimum SL.
VOTING The voting questions are contained in the VOTE.TXT. This
file is structured as follows:
Number: total number of questions
Text: line 1 ┐
Text: to line n: question text │ a
Number: total number of options (x) │ single
Text: line 1 │ question
Text: to line x: options text ┘
Text: line 1 ┐
Text: to line n: question text │ a
Number: total number of options (x) │ single
Text: line 1 │ question
Text: to line x: options text ┘
Text: line 1 ┐
Text: to line n: question text │ ...
etc.
Or to simplify:
n <- Total number of questions.
Text Q1 Line1 <- Question 1, can be up to 14 lines.
Text Q1 Line2
3 <- Number of options for question 1.
Option1 <- Each option. Can have up to 7.
Option2
Option3
Text Q2 Line1 <- Question 3, can be up to 14 lines.
Text Q2 Line2
4 <- Number of options for question 3.
Option1 <- Each option. Can have up to 7.
Option2
Option3
Option4
Text Q3 Line1 <- Question 3 on, same as before.
etc.
Example:
2 <-number of questions.
Do you like furry animals? <-question #1
3 <-number of options.
Yes <-option 1/3
No <-option 2/3
Yes when they are in a zoo. <-option 3/3
Do you like the great outdoors? <-question #2
4 <-number of options.
Yes, I visit them a lot. <-option 1/4
Yes, I have a garden. <-option 2/4
Yes, I have a plant at the office. <-option 3/4
No, burn it down. <-option 4/4
While you may only have a maximum of 7 of your own options
for a user to select from, the software also provides an
"Other" and "No Opinion" (the default) options for each
question.
When a user chooses "other" (the final voting question
option), they are prompted to enter text describing what they
mean. This can sometimes be a simple option you neglected to
include, or a whole complex belief idea. this text is then
sent to the sysop as a message from the AI. You may then use
their answer to decide if the voting options need more
options.
The "No Opinion" option is the same as not voting--and will
result in the question repeatedly coming up (next call) if
the voting is is being done at login. Because it is not
considered a real vote, the "No Opinion" selections are not
graphed either.
When an option's text runs into the graph, you will need to
shorten the option's text.
The graph shows all options except "No Opinion".
The graph automatically re-size's itself between 50% and
100%--to maximize graphic variability.
PSEUDO-AI The Pseudo-AI can only send private messages (E-Mail) in and
out of the Private Mail base, number 001.
Any messages redirected from the AI to the sysop go to the
sysop--not the message-op of message base 001.
I pretty much assume you will set the message-op of area 001
(Private Mail) to your name. You should not try to relocate
the private mail/e-mail/whatever from area 001 to another
number.
ACCOUNT VALUE Accounts do have value. The harder they are to get, the more
value they have.
Simple higher SL values increase their value.
Adding Peer Review increases the value of all passed
accounts.
Adding other requirements, such as name verification (users
send in proof of their name) or phone verification (call back
testing), further adds value.
Finally, stats are seen by all--so if a user has a lot of UL
credits, that account has worth.
What does this mean. It means you could have troubles as
accounts increase in value. More hacking attempts. Users
selling, or trading accounts. Probably other stuff I have
not thought of.
LIFE & DEATH There are many aspects to this capability, as it has many
DELETE requirements and conditions that must be met to both
implement it and for a user to use it.
To implement it:
Set the toggle to allow it to ON.
In "Change Settings", set a minimum amount of drive space
before this becomes active, and set a minimum user SL value
who may use it.
In your menus, have an entry for "Asst" (usually in your
login loop). Use an "ifSL" entry to give it the same SL
value as we do in Change Settings.
To remove it:
Set the toggle to allow it to OFF.
Remove the "Asst" menu entry.
Every thing is individual. "Asst" will display the AI help
request to anybody, which is why we set the SL field in the
menu command itself. When using the L&D system, any user may
attempt to delete it--which is why there is a Change Settings
SL value. That user could do it at any time, which is why
there is a "only if less than this amount of drive space"
Change Settings field.
It is complex because it needs to be. This capability allows
users to delete files from your download directories. So you
must be able to define who can delete and when they can do
it.
The way it is currently configured, just set the appropriate
Toggle to on to implement it with my defaults. Which are SL
value of at least 10 to do and must be less than one meg of
available upload space to do.
FILE When shelling to DOS--any changes you make in the text files
MANAGEMENT (such as BLOCKS/LINES/SHORT/etc.) either will not take
effect, will screw something up, or will crash the BBS.
Only after exiting the BBS, or full-dooring from the BBS,
should you then mess around with the BBS files. This is
because upon return the software will "know" which files you
altered. Whereas with shelling or shrinking, speed is
considered to be the important ability, so no "file
management" is done.
This includes the deletion of downloadable programs. While
it should not cause any trouble--why take the risk. Just use
<alt>r from the waiting-for-caller screen to remove a file
from the downloads areas (that is, do not do it when dooring,
after you have exited you can do whatever you like). None of
the dooring types recheck your file areas, or user and
messages files, as well as restarting the BBS itself does.
DOORS A door program is any program you temporarily pass control
too. Some doors do not use the door system: DSZ, PKZIP, etc.
Usually the door system is reserved for programs which also
communicate out the comm port. Although the door system is
also a convenience for defining programs to exit to for the
sysop.
Defining Use "Door Maintenance" from the Configuration menu to add
additional doors to the menu options, or to modify current
doors.
Door definitions contain the following fields:
Access start time
Access end time
Access to this door is allowed between, and including, the
time supplied here. If the two values are equal, then
access to the door is allowed during all 24 hours.
Maximum time allowed in door
The maximum amount of time a user is allowed in the door
per door access. The door handles this, so it is by no
means guaranteed. Use some high number (like 999) for
unlimited access time.
If the user's "time left today" is less than this amount,
then their "time left today" amount is used instead.
A zero value will still execute the door (it is always the
door's responsibility to guard the time) but if it is
handled properly by the door program, they will not be able
to use the door program.
Logging type
0 = none
9 = everything the door program has
1 to 8 are somewhere in between (door program defines, you
should look at the door program's documentation to see if
it supports this capability).
Minimum drive space needed
The minimum drive space (in bytes) that the door needs on
the drive to run. Usually this will be very small. If you
want to use 0, you should be sure the door program updates
no files (including the door-exit files). 2048 will be
fine for most doors, but some may need a lot more if they
need to update large data files (example, a daily packing
would need at least a megabyte--probably 2 or 3). So it
varies widely, which is why this field is here--the door
program will not be run if there is not at least this
amount of drive space.
Door-Op
Who is the door-sysop for this door. Only this name will
get sysop treatment from the door program.
Path
Drive\path specification of the door program. Example:
C:\BBS\DOORS or C:\BBS\DOORS\ or E:\ etc. It should
contain the path of the door programs' files.
This field is the drive that is checked to determine that
there is enough space. If empty, no space checking is
done.
Execution
Filename and command line to execute the door. If your
door program is at C:\BBS\DOORS\ABC.EXE you would put
C:\BBS\DOORS\ above and ABC.EXE here.
Command lines are of the form: ABC.EXE /a /k (in the
future, parameters like %1 for user name will also be
handled).
If you know what you are doing, you could define Path to
point to the door programs files, and have the door
program's executable somewhere else. Example: door's
files in C:\BBS\DOORS but door program at E:\ABC.EXE. You
would put "C:\BBS\DOORS" in Path and "E:\ABC.EXE" in
execution. Note, however, this will most likely only work
if the door program has a configuration file in which you
tell it where it can find its files--otherwise it will
assume they are at E:\ with the executable.
The following "%" macros are expanded when found in the
execution line:
%B Baud rate (2400, 4800, 9600, 14400, 19200, 38600) of
user.
%D Path to current door's directory.
%N Node (1..n) being used.
%L Transfer pathnames file to use (usually FNAMES.CTL).
%P Comm port (1..n) being used.
%S BBS's locked baud rate (2400, 19200).
%U Path to currently selected file area.
Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1"
(if comm port = 1 of course). That is, no leading or
trailing spaces are added.
These codes are the same as used by protocol execution
lines.
Calling To call a door program, you use the "DOOR" menu command.
This command is of the form: DOOR _EXITTYPE _FILETYPE _xxx
Where "xxx" is a number from 001 to 999 corresponding to the
record number in your Doors database.
Where "EXITTYPE" is the type of exit from the BBS you wish to
do. This field is optional.
Where "FILETYPE" is the type of door-exit information file
you wish to produce for the door program. This field is also
optional.
There are 3 types of EXITTYPE:
_shell
This is the quickest of the three methods. Fast at exiting
and fast at returning. It simply shells to DOS and runs
the program. Its limitation is that only the currently
available RAM can be used by the program. So it is not for
really large door programs. It is the method the software
uses for such things as protocols and archivers. Preferred
method for all door programs.
_shrink
This is the middle-ground of the three commands. It swaps
the program to disk, runs the door program, then re-loads
the program again. So you have delays when exiting and
returning. The advantage is that you have full memory
available for your door program. The delays are not
significant. This is the recommended method for large door
programs. The software first checks to make sure at least
400k of drive space is available before allowing the door
program to be run.
_full
This method is the odd-ball of the three commands. It is
as quick as shelling to exit, but as slow as the total
delay for shrinking upon return. It first completely exits
the program, runs the door program, then completely returns
(the user is kept on-line). It gives your door program
full memory usage.
There are 7 type of FILETYPE:
_doorinfo
This produces a DORINFOx.DEF door-exit file. Also known as
"RBBS" type file.
_doorsys
This produces a DOOR.SYS door-exit file. Also known as
"Gap" type file.
_wwiv
This produces a CHAIN.TXT door-exit file. Also known as
"WWIV" type file.
_spitfire
This produces a SFDOORS.DAT door-exit file. Also known as
"SpitFire" type file.
_pcb12
This produces a PCBOARD.SYS door-exit file. Also known as
"PC-Board 12.x" type file.
_pcb14
This produces a PCBOARD.SYS door-exit file. Also known as
"PC-Board 14.x" type file.
_wildcat
This produces a CALLINFO.BBS door-exit file. Also known as
"WildCat! 2.x" type file.
See TECHDOCS.DOC if you want detailed information about the
door-exit files.
Upon exit to a door, a JDRBBSxx.DEF exit-information file is
created in the directory defined in Path (see Defining).
See also: FILE MANAGEMENT
Executing The door program is executed when a user selects the hot-key
(you defined) from the menu (you defined) for the door (you
defined).
What occurs (???'s are replaced by node number, eg. 001):
DOOR???.BAT is created. It contains:
d:
CD \path
execute
C:
CD \BBS
BBS???.BAT
"d:" is from the door Path field.
"\path" is from the door Path field.
"execute" is the door Execute field.
"C:" comes from PATHS.DAT.
"\BBS" comes from PATHS.DAT.
"BBS???.BAT" comes from PATHS.DAT.
BBS???.BAT contains:
@ECHO OFF
SHROOM @SHROOM.YES JDRBBS.EXE
DOOR???.BAT
You can see how it works. You typed BBS001, which ran
BBS001.BAT, to start the software. At that time, DOOR???.BAT
contained just a REMark line.
Now DOOR???.BAT is given something, so that when we exit, it
changes to the appropriate directory, runs the program, and
returns back and re-runs BBS???.BAT.
Upon return, the software checks DOOR???.BAT, finds that we
are returning from a door, and acts accordingly. It also
resets DOOR???.BAT to contain just a REMark--so that we exit
the program in the future.
The above DOOR???.BAT file might look familiar. Most doors
come with a batch file that looks something like so:
COPY door-exit file to door directory
CD to door directory
run door program
CD to BBS directory
Ignore these! The BBS handles all the movement/etc. Just
specify the door directory in the Path field, and the door
program execution line in Execution field, and it will work
fine.
Let me re-iterate this. You define the door program to run--
you could define a door batch file, but not normally--the
software creates its own batch file which moves you to the
door program's directory before executing it, and returns you
to the BBS's directory upon exit. This is an extremely
convenient feature, and most doors go out of their way to
describe a batch file for you to create--I am saying that for
the most part you can ignore that hassle.
For _shell and _shrink methods the batch files are not used,
instead the software internally does all the same commands,
and then just calls and does the "execution" line of the
door. Thus, all three methods have the hassle-free door
execution procedure.
Time Like file transfers, time spent in doors is reduced from the
Maintenance daily time available, and if need be, from minute-credits as
well.
A user may call a door as many times as they want. You may
set a "maximum time" a user may spend in a door per session,
but since a user may use the door any number of times,
ultimately they are limited by their total time available.
Before calling the door, the software will verify that they
have time available.
A door program gives minute-credits, or removes them, for
reward or loss, respectively. If a door program you are
installing has the ability to define the rate of exchange
(example: 1 minute-credit = $100,000) then set this value
such that the highest a user would ever attain (in total)
does not exceed 32,000 and the lowest they ever attain (in
total) is not below -32,000. Minute-credits should not
casually be played around with in the doors, they should
represent seriously high goals in the game. A gambling door,
for example, should not use 1:1 minute-credit ratios, but
rather the byte part of the exchange rate ($1,000,000 or
$10,000.00).
Upon return from the door, time used in the door is handled
like it is handled with bidirectional transfers--if the user
exceeded the time they were allowed in the door, exchanges
will be done, and it is possible they could end up
"borrowing" from future uploads.
When a user's minute-credits reach or exceed 32,767, it will
never increase. When it reaches -32,767 it will not be
reduced farther.
Misc. If you give a user temporarily higher security level, and
they run a door, then that temporary level becomes their new,
permanent, level.
I have been testing some of the door programs with this
software, see the file DOORS.DOC for helpful information on
various door programs.
To speed up the loading of doors, use PKLite or a similar
utility on the .EXE and .COMs. However, if you get the
message "has overlays, continue?" then do not continue--these
programs, like JDRBBS.EXE itself, have internal overlays that
cannot be accessed if they are compressed.
When run as an event, no time checking/handling is done.
Since there is no user.
If you set something up wrong, the good door programs will
tell you what was wrong.
PROTOCOLS All download protocols must contain a "@%L"--this expands to
"@C:\BBS\NODE.???\TEMPAREA\FNAMES.CTL" or whatever name you
assign. All protocols must be able to do batch transfers,
and accept a file containing those pathnames the caller
wishes to download. The "@" is not required, some software
package may prefer "&" or some other weird character.
The following "%" macros are expanded when found in the
execution line:
%B Baud rate (2400, 4800, 9600, 14400, 19200, 38600) of
user.
%D Path to current door's directory.
%N Node (1..n) being used.
%L Transfer pathnames file to use (usually FNAMES.CTL).
%P Comm port (1..n) being used.
%U Path to currently selected file area.
Note: "%P%P%P" expands to "111" but "%P %P %P" is "1 1 1" (if
comm port = 1 of course). That is, no leading or trailing
spaces are added.
These codes are the same as used by door execution lines.
The protocol database has the following fields:
Defining letter
This is the letter the system uses internally, and the
user sees for "protocol" in their Profile, of the defined
protocol. If you use two letters that are the same, you
should be sure that their SL ranges do not conflict.
Minimum SL needed
This is the minimum SL a user needs to have before the
system lets them select this protocol.
Set this higher than any SL to disable this protocol.
Maximum SL allowed
This is the maximum SL a user needs to have before the
system lets them select this protocol.
Using a min SL and a max SL allows you to direct
different flavors of the same protocol to different
users. Example, in my set up, level 5 users do not get
to do resume-later upload aborts, and so I use a DSZ line
that does not save incomplete files for that security
level.
If this value is zero, then it is ignored. Allowing any
SL once the minimum SL requirement is satisfied.
Success UL letter
This is the letter, when found in the log file, that
declares that the upload was successful.
Fail UL letter(s)
These are the letters, when found in the log file, that
declare the upload a failure.
See Fail DL letter(s) as well.
Success DL letter
This is the letter, when found in the log file, that
declares that the download was successful.
Fail DL letter(s)
These are the letters, when found in the log file, that
declare the download a failure.
Technical note: The following is fairly detailed, and
you may not ever need it (recommend you read it only if
you are having troubles detecting bad uploads):
In order for the to correctly identify bad transfers,
either this field must be one character, or the pass/fail
determining word must be one character. Example: DSZ's
pass/fail word is either "E" or "L"--one character. So
you can have up to 3 characters here ("LE"). If some
other protocol has "Bad" for failed transfers and "Good"
for successful transfers, then you must put a "B" or "a"
here, not "Bad", not "Ba", not more than one character--
because the pass/fail determining word is more than one
character.
To simplify: the software looks for the "Fail letters"
inside the "pass/fail determining word" and looks for the
"pass/fail determining word" inside the "Fail Letters".
If either of these cases come up true, then the transfer
is determined to have failed.
This allows me to find: "L" or "E"--rather than trying to
find "LE" in the pass/fail word. So, while "LE" will not
be found in "E", "E" will be found in "LE". If you have
"LE" and the protocol leaves multiple letters, such as
"Lbad", then it will not find the "L"--since either "LE"
will not be found in "Lbad" and "Lbad" will not be found
in "LE".
Pass/fail determining word
This is the "word number" of the letter that determines
whether the transfer was successful or not. The word
number of the log entry.
Words are defined as text having a least one space
between them. Example: "A B C" has 3 words, but "A BC"
has only two. If the protocol produces entries that are
some times blank (rather than, say, a zero), then you
cannot use it (unless the trouble occurs after the
determining and pathname words).
Pathname word-number
This is the "word number" of the transferred pathname in
the log file.
The pathname need not contain a full file path. It
should at least contain the file name transferred.
Percentage of time to give
This is the percentage of upload time (as determined from
2400 baud) that you should give in minute-credits.
No time is taken off for uploading, except with
bidirectional protocols.
Description
This is the text the user sees when selecting and using
the protocol.
Log file pathname
This is the full path and file name of the file in which
the protocol keeps the log of what happens.
Upload execution
This is the execution line we should use to handle
uploads to the BBS.
In both execution lines, you should include the full
pathname of the protocol driver being used. Example,
"C:\BBS\DSZ.EXE".
Download execution
This is the execution line we should use to handle
downloads from the BBS.
The very first protocol is known as the default protocol, it
is given when the user's selected protocol (somehow) has no
allowable match. The internal terminal program always uses
the default protocol. You may reassign the default protocol
by using a defining letter of "*".
You must have a BiModem entry, and a Zmodem entry. BiModem
execution lines must allow for the "/T" restriction (so you
should not use /T with your BiModem line).
EVENTS All events are done after a user logs off, or after the "Not
before" time has passed when no user in on-line. Example: a
00:00:00 does not occur at 00:00:00. But at 00:00:01 if no
user is on. If a user is on it will be executed after they
log off.
There is no forcing a user off for events, or reducing their
time for an event.
You can turn off an event by not giving it any days of the
week.
NETMAIL AND
ECHOMAIL
Overview What is net mail?
A "net" is just a bunch of computers.
"Net mail" are messages exchanged between computers.
Usually each net requires a special type of net mail. That
is, if a computer you wish to send mail to is not a member of
the net to which you subscribe, then you cannot exchange
mail. Examples of different nets range from FidoNet and
InterNet to LAN nets to simple me-and-my-friends nets.
Lately, there has been an effort to merge nets, and allow the
exchange of messages between these nets. As well as efforts
to standardize message formatting and other aspects of inter-
computer communications. However, at this time I do not have
the various specs, but will expand as I get the specs.
This software supports the net type known as "FidoNet".
FidoNet uses a three number "node ID" for each member of a
network. It is organized as: Zone:Net/Node
Zone means "1" for FidoNet, other numbers for other nets.
JDR_BBS supports Zone's up to 32767, but most other net mail
software only goes to 255--so you may want to limit your Zone
number for your net when you know you will be interfacing
with these other mailers.
Net means a sub-net. Sub-net's are used to more efficiently
and cheaply more mail and files around the net. Usually
these sub-net's represent all the net members in a local area
(city, part of a state, etc.). This hub is responsible for
picking up mail from each member, and dropping off new mail
to each member.
The last field is Node. These are individual members in the
sub-net. The "local address" of that member so that the sub-
net coordinator (hub) can tell who is who.
All three together form what is known as your "net address"--
completely unique from anyone elses. Note that standard
writing of a net address is as "Zone:Net/Node", but when
entering a net address in this software you may type anything
for the "betweener" characters. Example: "Zone.Net.Node"
works. So you do not have to remember the confusing ":/".
FidoNet is the most widely used net in the PC world. It uses
a specific address format and has lots Hubs which provide
significant cost savings.
A net mail session involves sending packets to and from
another member (or hub). Packets are messages stored into a
single file for transmission.
To get an "official" net address, you must contact your
area's hub (or somesuch) and ask them for one. You will need
to get at least one net address for each zone (net) to which
you wish to be a member. Different nets exist for a variety
of things.
NetMail NetMail is a type of message area. Messages left in this
message area do not go to a bunch of addressees, but rather
each message is destined for a specific address.
To define a message area as NetMail, give it the NET
attribute (but not the ECHO attribute).
There are only two types of NetMail: private and public.
However, you can create message areas that have a minimum SL
requirement. This can be useful to create a private NetMail
message area among sysops, for example, while also having
private and public NetMail message areas for all users to
use.
NetMail, and EchoMail also, differ from regular messages in
that they contain "hidden" lines which provides information
about who and where the message was sent from--no matter
where it finally ends up.
NetMail can be thought of as a point-to-point mail system.
You create a letter, and you want it to go to another BBS.
EchoMail EchoMail is a message area type.
It relies on "routing" to decide where messages are to be
sent.
EchoMail message areas are centered on one BBS. This is
known as the originating BBS.
To become a member of an echo, you must call up the
originating BBS and ask to be placed on the list of BBS's
receiving the echo.
You need to set up a message area to receive this echo's
mail. From the originating BBS, you get what is known as a
"conference name" (also a "tag name"). You use this in the
"EchoMail mapper" I have--connecting this name with the
message area you want to receive the messages. You may
reference multiple names to a single message area (combining
echos--but outgoing messages will always be references as
being in the first conference name for that area).
You must also create this message area with the NET and ECHO
attributes.
The next step is routing. Use the "Outgoing EchoMail
Routing" command for this. This database only has three
fields: message area, net address, and last-read pointer.
The message area is an EchoMail area. The net address is the
net address of your originating BBS. The last-read pointer
is the highest message number that that BBS has seen--it's
mainly internal, so you need not worry about it.
Once done, whenever a message is posted on the originating
BBS, that message will then be sent to all member BBS's (of
which you have become one). This is done according to a
schedule the originating BBS sets up--usually based on
message volume.
Similarly, when you post a new message in that area, it will
be sent to the originating echo BBS, which will then re-send
it to all member BBS's. This you decide. If you route via
your local hub, then the cost is minimal, but if you have to
call long distance, than once a week might be more cost-
effective.
There are two flavors of EchoMail: EchoMail, and Conference
Mail.
EchoMail consists of a single originating BBS, and a bunch of
subscribing BBS's. Sending messages can be imagined as
fireworks: you launch new messages up to the originating BBS,
and that BBS launches the messages out to all the subscribing
BBS's (an umbrella).
Conference Mail is slightly different in that all subscribing
BBS's are considered originating BBS's as well. This means
it is the responsibility of each BBS to send new mail to all
the other BBS's--this helps distribute costs.
Typically, routing files will only have a single line--that
of the area's originating BBS for EchoMail. However, if you
are an originating BBS, or the echo is a conference, than
your routing file will have entries for all the BBS's you
wish to send duplicate copies of any new mail too.
The software stops re-sending of messages back to the BBS who
sent them to you. So do not worry about duplicate messages.
FidoNet FidoNet is the most popular PC-based net. It offers the
advantage of cost savings.
FidoNet requires a FidoNet address. To get one, you should
talk to the sysop of BBS in your area who is getting FidoNet
echo's. Ask him which BBS he should call. Then call that
BBS and ask the sysop for the procedures to get a FidoNet
Address.
Currently, these procedures involve giving your address and
voice phone number (they do not explain why). You'll also
need to pay a small fee (usually under $20) per year.
Once done, or not, you'll need to get your hands on the
latest NODELIST.xxx file. These have a variety of names, but
should be on the area coordinator's BBS. It's hefty--it'll
expand out to 1.2+ megs. It contains all the other BBS's in
the FidoNet network.
These "member lists" are common to all nets you join--each
has their own, although few exceed 20k in size.
You need only unpack the node list and add an entry in your
node list database referencing this new (or changed) node
list. The next time the BBS is restarted, it will
automatically discover it as new (or changed--such as when
you edit it) and re-index it properly for the software's use.
Hubs Hubs are where the great cost savings of a net come in. You
route all your outgoing messages through a hub.
Instead of having to call each address, usually long
distance, you can call your hub, usually a local call, and
they will route the messages to any other address in the
world for you at no additional charge.
It is the simple hub-and-spoke system. Airlines and shipping
companies use this method as well. It is quite common, and
very efficient.
You must be a FidoNet member to use FidoNet hubs, and the
messages you route through the hub must be destined for other
FidoNet members. These other members can be local addresses
or long distance or even international. The same is true for
each other net.
Hubs go through a procedure known as polling. In which you
call them to get/receive new mail, or the hub calls you to
drop off/check for new mail. Usually this is done each
night--but any schedule is possible.
For now, you should tell your hub to poll you. This is
because I have a rather sophisticated polling routine in the
works and it isn't ready for this release. You can use
"dHUB"--but it is not fully ready yet, as it only does one
calling attempt.
Costs Both NetMail and EchoMail rely on the BBS that posted the
message to foot the costs for actually sending the message.
So, if you have a hub, then the costs will consist of the
yearly fee, and any local charges to call the hub.
If you do not have a hub, you will have to pay the costs to
call the BBS's yourself. The good thing about this is you do
not have to do it everyday for every echo. You can do it,
for example, once a week, and you only need to do it when you
have mail to send.
If you wish to have an EchoMail area, and you do not have
access to a hub, you should specify that those that want to
receive your echo should call you ("to poll you"). If you
have a hub to access, then it is easier to just send mail out
to them.
Misc. The software does not use NODEDIFF files (which your hub can
supply) to update the node list. It instead relies on you
copying the whole new list over the old list. However, you
may do "quicky" updates (adding an address or few) by
creating a separate net list containing these new addresses
(just remember to have the Zone and Host lines proper).
After a NetMail message has been successfully sent, it has a
SENT flag set--so it will not be re-sent. You can alter this
flag by editing the message's header information.
If an EchoMail packet accidentally got deleted by the
receiving BBS, or whatever, you can just change the "last-
message-seen" pointers in the routing entry for that address
to have the messages re-sent next time.
Whenever an exchange of mail occurs, both mail you wish to
send, and mail waiting for you, are exchanged. That is, you
do not have to call once to drop off, and again to pick up.
Messages are given the date/time of when they arrive to the
BBS--not the date/time when the message was created on
another BBS.
Same for message numbers. Messages are given the next
message number in your message areas--not the message number
used by the originating BBS.
If you run out of drive space when importing messages, the
.PKT will be moved to your \BBS directory. It will remain
here and await for you to import it manually when you have
enough drive. Manual import can be done by specifying the
.PKT file's pathname when entering messages with the Upload
(import) option ON.
Commands There are 3 basic commands to handle net mail:
NETa To contact all members of an EchoMail area and attempt
to exchange mail with them. Long Distance charges
would add up quickly were you to use this. It is
mainly for local or private nets. It makes one attempt
at each address. If contact is made, then all messages
in all areas destined for that address are sent. So
while it uses a message area to decide which addresses
to call, it will send that address any mail in any area
they have waiting.
<end> This is the key you may press after you call a BBS.
This command will send any new messages meant for the
BBS. If you used "d string" to dial, then it will use
the net address in your sysop's database--otherwise it
will ask you which address to use.
Unless you belong to a hub, this is the command you
will probably most use.
If an EchoMail area only routes to the originating BBS,
then NETa is like an event version of this command.
Some mailers will require that you wait until the BBS's
(that you called) is no longer sending anything--if you
are having troubles by hitting <end> right away, or
while something is displaying, then wait until the
display stops.
How many messages you can send with the <end> command
relies on two factors: your computer's speed, and the
wait the called computer is willing to endure.
Usually, the limit is whatever your computer can pack
in thirty seconds.
dHUB This command will make a single attempt to call your
hub. If successful, it will drop off any new messages
to addresses which have mail coming and have the same
zone as the hub.
This is the preferred command to exchange mail, if your
hub cannot poll you.
Unfortunately, at the last minute, I noticed a problem:
multiple nets mean multiple hubs and multiple net addresses
for you. My mistake. However for now Settings allows you to
only define one net address for yourself, and one for your
hub. There is no easy way around this. Keep the values at
your main net for now, then change them and use <end> for
other nets. This will be fixed next version (I'll also add
AKA support).
See also: MENU COMMANDS
Not Ready The software cannot handle some of the net operations
specific to hubs. It does not "store and re-send" packets,
but creates and unpacks them when needed or received.
An "intelligent" dialing system. Such as repeat-until-answer
and intelligence needed when calling other nodes.
AKA addresses for net nodes.
Password protection schemes for net nodes.
Handling of specific hours in which a BBS accepts mail.
Lots of other minor stuff.
Registered sysops get to do file transfers and send
compressed message packets.
MULTI-NODE/ With .08 the BBS is now undergoing "alpha" testing of multi-
MULTITASKING node operations. By "alpha" I mean I think it'll work, but
OPERATIONS those of you who want to try it--let me know what happens and
what is needed still.
Protocol logs need to be made "multi-node-able"--I haven't
looked into it yet, but you can get around this by simply
specifying the protocol log to be put in a NODE.??? area
(although this doesn't solve the environment SET's that some
use).
Also, there as yet is no "inter-node cross-talk". That is,
not only can't users talk to another user on another node,
but the BBS doesn't know who's on the other node.
SHARE.EXE will need to be installed for multi-node operations
under MS-DOS and DesqView (not sure about Windows, or OS/2).
I don't use any kind of fancy record-locking or file locking.
I merely open all files in "deny none" mode, and assume DOS
properly handles the job (that when you do an INT 21h to
write to disk, that another INT 21h cannot be done at another
node while the first one is midway though).
I'll probably do inter-node stuff for the next release, and
some minor testing with DesqView and declare it done. But it
probably works now.
One thing that should really be useful is a "sysop node"--you
set up a node that nobody can contact via the phone, and just
switch to that multi-task window when you want to logon.
This allows you to avoid waiting to access your own BBS.
Do not let users on more than one node.
There is no serious checking for one node "re-working a file"
and the other nodes (for instance, the sysop doing a pack
files).
Events will each run on each node for now.
These problems will have to be knocked down one at a time.
INTERNAL NETS This involves connecting computers via a null modem and using
JDR_BBS as a medium on one or more of your computers.
You must specify in your fossil driver line each port. For
instance, I have an HST connected to COM1 and a null modem
connected to COM2, and use the following CONFIG.SYS line:
driver = x00.sys 2 b,0,19200 b,1,19200 r=4096 eliminate
There are two ways to connect up two computers via a null
modem using JDR_BBS.
The first method is for when both computers are running
JDR_BBS. This involves going to the waiting-for-caller
screen of both computers, and selection <alt>p and changing
two whatever comm port the null modems are connected to.
This is a hard link, from which you can use <alt>s, <pgup>,
or <pgdn> only.
The second method involves JDR_BBS being on one computer run
as a straight BBS, and JDR_BBS on the other computer in
<alt>d. For both computers, you will need to first use
<alt>a to set the comm port to your null modem--you will need
to repeat this step when you are done. This allows you to
use all the <alt>d commands.
You can mix and match the above, <alt>p, <alt>d, <alt>a, it
does not really matter. What matters is that you get both
computers pointing to your null modem.
It might be more convenient to set up multi-tasked "sysop
nodes" on each computer already pre-configured as a null
modem connection. Giving it no timer ticks until you need
it.
FILE With all the I/O being done, it is inevitable that you are
CORRUPTION going to get some sort of file corruption.
Executing a: CHKDSK /F will fix these problems.
However, CHKDSK may fix it by increasing a files size
(particularly for allocation errors). For text files this is
not a problem. For the USERS, FILELIST, and MESSAGES.HDR,
you should run the appropriate integrity testing command.
For other .DAT files, you can use their Databaser menu
command to edit them to find any visible problems.
If you have Trap All ON, and shell to DOS and delete the
SESSION.LOG file, you most likely will get a fatal "sector
not found on drive d:" and have to reboot the system. This
occurs because I do not close my files when shelling to DOS.
The reason I do not close them is because <alt>s could be hit
anywhere, and I have no way of knowing which files are open.
DOS does not like you deleting its opened files.
If any of the .IDX index files become corrupt, just delete
them and restart the BBS, they will then be recreated (you
should restart all nodes). You can tell the users index, for
example, is corrupt if you are not allowed to enter what you
know to be a valid user's name, or if the data returned about
an account is wrong, or that of another user.
TROUBLE- If you crashed you BBS while in a door program, you should
SHOOTING delete the DOOR???.BAT file. If you do not, then every time
you try to exit the BBS, it just runs this batch file
thinking a door is being run (this occurs until you
successfully return from a door if you do not delete it).
If you are testing door programs, or trying to track down
something in one of the door exit files (DORINFOx.DEF, etc.),
then just run JDRBBS.EXE (not BBS???.BAT)--after you select
to exit the BBS to a door, the system shuts down (because it
could not run the DOOR???.BAT file from BBS???.BAT), allowing
you to look at the door exit files, or test door programs
using the same door exit files.
"Device I/O" errors usually means you have specified a
pathname that cannot be found, or cannot exist.
"String space corrupt" is a programming error--and if you can
duplicate it consistently, please tell me, as these errors
usually occur a while after the actual bug itself. So are
very difficult to track down.
"Cannot execute filename" is an error that appears when you
run a door program in _shell method, and the program needs
more RAM (so run it in _shrink or _full method).
If when you restart the BBS and it does not clear the screen
and display the copyright when loading the indexes--then it
is due to you loading a TSR that uses up too much memory.
If the software does not record in the callers log the data
from protocol log files, or the software does not recognize
file transfers, then this is due to you not properly telling
the software where it can find that protocols log.
If the software does not record in the callers log the data
from net mail transfers, or does immediate hanging-up after
sending or receiving a packet, then you should make sure that
the DSZ protocol log pathname (see PATHNAMES) is correct.
PERFORMANCE Anything you can put into a RAM disk will speed things up.
ENHANCEMENTS
Doing a weekly packing will also improve overall performance.
A disk cache might improve performance--has not been tested.
It might be better to use the memory for a RAM disk. A disk
cache that knows the difference between a RAM disk and a hard
disk (and only caches the hard disk) would be useful.
Using NU's SpeedDisk or some other disk defragmenter really
helps--BBS's are a natural fragmenter of files--I recommend
once a week.
Both the packing and defragmentation can be done as an event.
For the defragmenter, just set it up as a full-exit door.
If your BBS computer will only be for the BBS, I recommend
you put the following into a RAM disk:
File 640k 1MB 2+ MB
LINES.$$$ √ √ √
FX.TXT √ √ √
CMDS.DAT √ √
MENUS.DAT √ √
BBS_CMDS.DAT √ √
most used .ANS's √ √
USERS.IDX √ √
FILES.IDX √ √
JDRBBS.EXE √
640k, 1MB, and 2+ MB are how much available RAM you have.
MENUS.DAT, BBS_CMDS.DAT, and CMDS.DAT are part of the menu
system. You should not put these into RAMDRIVE until you are
fairly sure you do not want to make any more menu changes.
Because McEditor will change these files--and if they are on
your RAM drive, then the changes are not copied back to your
hard drive.
Putting the .IDX's above in a RAM drive means they will be
deleted when you reboot the computer. This is no problem,
since the software will just rebuild them right back up. So
it is practical to keep the .IDX's on a RAM disk--and if you
keep auto-name-detect and auto-filename-detect ON, then I
would recommend you put USERS.IDX and FILES.IDX on the RAM
disk.
Remember that files in \RAMDRIVE are automatically updated to
the RAM disk whenever you change them. So there is no need
for you to copy files to your RAM disk yourself.
If you really want to put files that get updated onto your
RAM disk, I would recommend you put a line to copy these
files back to your hard disk in your BBSxxx.BAT file after
JDRBBS.EXE is run.
In general, the software has been designed to be very
flexible. Allowing you to decide on the best allocation of
your resources.
While putting LINES.TXT onto a RAM drive and defragmenting
will speed things up--that is not the main reason to do so.
The main goal is to reduce wear and tear on your hard disk by
doing so.
REGISTERED Besides the stuff in ORDER.FRM, Registering will get you a
PACKAGE modified/complete version of JDRBBS.EXE which includes the
things below.
The purpose of the registered package is not to cripple the
operations of the BBS, or penalize the users. It provides
enhancements that a sysop would like. Since, ultimately, it
is the sysop who registers this.
You are also limited to like 2000 active users and 2900
active files. Whereas the registered package boosts these
numbers at least into the 20,000's.
DataBaser You get the source code for this module.
Net Mail File The capability to do netmail file transfers is also separate
Transfers from the unregistered version.
The registered package includes the necessary module to allow
you do and handle file requests. It is required if you want
to send compressed messages--which results in reducing by
half the packet/messages transfer time over the phone lines.
This feature both saves money and time.
It is also quite nice to set up a file exchange net with your
fellow sysops (just like net mail, but with whatever new
files are put into a specified area(s)).
Sysops This is a collection of routines not included with this
Package version. Most new sysop routines will be going here. These
are all sysop enhancements--none for the users.
The following additional menu routines are included with the
sysop package:
Alter L&D
--Alter L&D/File Point values globally per area.
Directory
--Lists the contents of any directory in DOS style two
column form.
DL Potential
--Lists users by security level, including information
about their "bytes can download" and minute-credits
availability.
File Lists Comparer
--Will compare two lists of file names and descriptions
(from other BBS's lists or Master Lists) and produce a
third list of files that are common, different, or
unique using the two lists.
File Spell Checker
--Will check the spelling of all words in a text file,
putting all not-found words into a file.
Fix User SL's
--Allows you to change all user security levels from one
value to another.
Global File Area SL changer
--Allows you to change many file area SL limitors at the
same time.
Pack Files
--Does the purging of deleted records from the data
files. Put here because a sysop who uses the BBS for
less than 30 days has no need to pack so soon. If you
do not pack your data files, they will continue to grow
ever larger, and eventually the bloat will slow the BBS
down noticeably.
Post Upload Processor
--Allows you to run files that are on-line through the
same post-upload procedures that uploads go through.
Including comment header and virus checking stuff.
Print Out Messages
--Print out all the messages in a message area to a file.
Includes deleted messages.
Strip ANSI & Avatar
--Will selectively strip ANSI and Avatar codes out of any
file.
Vote Summary
--Summarizes the voting results in tabular form.
The following capabilities are turned ON with the registered
package:
Add Comments
--To automatically insert your BBS's comments into the
header of ZIP or ARJ uploads.
Extract Comments
--To automatically extract ZIP header comments out of
uploads and save them to a text file (so you, and/or
your users, can know more about the BBS's from which
the files came).
Import .DIZ descriptions
--To automatically insert a .DIZ description file from an
upload and place it into your file reviews.
NEXT MENUCMDS should be your next stop.